An Android app is a software application running on the Android platform and is specifically designed for a smartphone or a tablet PC running on the Android OS. However, Android apps depend on a runtime environment provided by the Operating System in order to execute. The Android Operating System has been designed to be ported to multiple devices allowing existing apps to run unmodified on those devices.
A majority of the Android OS subsystems is required to provide the runtime environment for running apps. Some of them are optional and vary based on the capabilities of the computing platform. Android was designed with this flexibility of device capabilities allowing the Android Operating System to be ported to a different range of devices. As a result, Android Apps cannot be run on any Host Operating System other than Android.
An existing solution to provide access to Android apps in a foreign Operating System is to use a Virtual Machine. Third party solutions exist with varying capabilities of the virtual environment. Other solutions also exist to run Android Virtual Machines in a cloud host and stream the output of the virtual display down to a different device giving the impression of running Android locally.
Irrespective of the various solutions mentioned above, all Virtual Machine based solutions share the same design ie. a Virtual Machine executes all the necessary Android subsystems to run apps, isolating the Android environment from the host. However, there are several problems that arise with the design.
One such problem requires the users to change their behavior while interacting with host apps and virtualized Android apps. This happens because of the varying semantics of the host OS and Android apps. Consequently, the users are frustrated and confused of the switching underlying OS. Further, the apps may be visually very different as the host OS and Android are not designed with the same visual guidelines. Another problem arises as a result of varying file system architecture. Data is not transparently shared between the Host and virtualized Android OS. For instance, if the Host OS has a contact list, the contact list will not be available in the visualized Android. In an attempt to improve integration, subsets of data can be synchronized between the Host OS and virtualized Android OS. Similarly, apps of the Host OS and Android OS cannot interact directly. Android OS uses a catalog of installed apps maintained by the Package Manager Service. None of the Host apps are listed there making them invisible to all apps in the visualized Android environment. The same applies to the Host OS wherein Android apps cannot be reached via native Inter-Process Communication (IPC) mechanisms, making them generally unreachable to host OS apps.
Further, an entire VM is required even if the user requires access to a single Android app. The VM needs to be started with all necessary components to support the Android runtime. The amount of resources used by the environment may greatly exceed the resources needed by the Android app itself. The high resource requirement prevents VMs from being deployed to devices other than servers and desktops, such as mobile phones and tablets.
Furthermore, Android is designed to be executed in a single computing environment. This limits cloud environments where a large set of hosts is available. It is not possible to spread the computation of a single user among multiple hosts, the entire VM has to be moved to a different host for load balancing. Similarly, starting and stopping the VM in a cloud environment is a resource intensive and time consuming operation.
In the light of the above discussion, there appears to be a need for executing Android Apps natively on any environment.